fix(ci): move the repo user-agent to where pnpm v12 reads it by zkochan · Pull Request #10552 · teambit/bit

zkochan · 2026-07-31T14:58:26Z

Summary

The user-agent in .npmrc exists so installs run inside this repository can be told apart from real users' installs at the registry. Two things were wrong with it.

It stopped working. pnpm v12 reads settings like user-agent from pnpm-workspace.yaml, not .npmrc. Verified against a local server that logs request headers: with user-agent=bit-repo-local in .npmrc, the install sent the default pnpm/12.0.0-alpha.21 npm/? node/? linux x64. Bit's own installs did not use it either, because getNetworkConfig takes configuredUserAgent from the engine's resolved config (readConfig), which does not read it from .npmrc (scopes/dependencies/pnpm/pnpm.package-manager.ts:314-319).

It accumulated one line per release. setup_harmony appended the marker to the tracked .npmrc and then persist_to_workspaced the checkout, so the job that creates the version-bump commit swept the mutated file into every release. The file had reached thirteen lines, twelve identical. And because duplicate keys in .npmrc are last-wins, those committed CI lines also overrode bit-repo-local for anyone working locally, so the local/CI split had been inverted for twelve releases:

$ printf "user-agent=bit-repo-local\nuser-agent=bit-repo-circleci\n" > .npmrc && npm config get user-agent
bit-repo-circleci

What this PR does

Adds pnpm-workspace.yaml with userAgent: bit-repo, which is where v12 reads it. Verified in this repo: readConfig({dir}) returns bit-repo, which is exactly the value getNetworkConfig forwards to the engine, so local and CI installs in this repo both carry the marker again.
Removes the append from setup_harmony, so no tracked file is mutated and the accumulation cannot recur.
Deletes .npmrc, whose only contents were the dead user-agent lines.

One name now covers local and CI. The split was inverted for twelve releases, so nothing downstream can have been relying on it, and a single bit-repo is enough to filter this repo's traffic. If you do want them separated again, add pnpm_config_user_agent=bit-repo-circleci to the job environment: it overrides the file and needs no file mutation (verified, the request went out as bit-repo-circleci). Note npm_config_user_agent does not work with v12, only the pnpm_config_ prefix.

Also worth knowing, though left out of scope here: the e2e job appends user-agent=bit-e2e-circleci to ~/.npmrc (.circleci/config.yml:542), which is inert for the same reason. The bvm bundle jobs are fine, since they write a throwaway .npmrc and run pnpm 10, which does honor it.

Squash Commit Body

The marker exists so installs run inside this repository can be told apart
from real users' installs at the registry. It stopped working: pnpm v12 reads
settings like `user-agent` from pnpm-workspace.yaml rather than .npmrc, so an
install with `user-agent=bit-repo-local` in .npmrc sends the default
`pnpm/<version> ...` header, and bit's getNetworkConfig reads the value from
the engine's resolved config, which does not take it from .npmrc either.

Set `userAgent: bit-repo` in pnpm-workspace.yaml, which readConfig surfaces
and getNetworkConfig then passes to the engine, so local and CI installs in
this repo both carry it.

setup_harmony had also been appending the marker to the tracked .npmrc before
persisting the checkout, so the release commit swept it in and the file grew by
a line per release, twelve so far. Because duplicate keys are last-wins, those
committed CI lines also overrode `bit-repo-local` for local work, inverting the
split. Remove the append and the file.

Checklist

Added or updated tests. Not applicable: CI configuration and config files, which the suite does not cover. Verified by hand instead: the sent header against a local logging server for each mechanism, readConfig({dir}) in this repo returning bit-repo, bd install in this repo still succeeding with the new file present (332 components, no other tracked file touched), and yaml.safe_load on .circleci/config.yml.
Updated the documentation if needed. The reasoning is a comment in pnpm-workspace.yaml.

Written by an agent (Claude Code, claude-fable-5).

qodo-free-for-open-source-projects · 2026-07-31T14:59:06Z

PR Summary by Qodo

Fix CI: prevent CircleCI user-agent from persisting in tracked .npmrc

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Prevent CircleCI from committing a mutated tracked .npmrc into release bumps.
• Restore .npmrc after CI install via EXIT trap, even on install failure.
• Collapse .npmrc back to the single intended local user-agent entry.

Diagram

graph TD
  A(["CircleCI: setup_harmony"]) --> B["bbit install step"] --> C["Append CI user-agent"] --> D[(".npmrc (tracked)")] --> E["trap: git checkout .npmrc"] --> F["persist_to_workspace"] --> G["version bump commit job"]

  subgraph Legend
    direction LR
    _job(["CI Job/Step"]) ~~~ _file[("Tracked file")] ~~~ _action["Command/action"]
  end

High-Level Assessment

The following are alternative approaches to this PR:

1. Set user-agent via environment (NPM_CONFIG_USER_AGENT)

➕ Avoids mutating tracked files entirely
➕ No need for git-based cleanup/traps
➖ May not be honored by all involved tooling (npm vs pnpm vs custom wrappers like bbit)
➖ Harder to ensure the value reaches all subprocesses consistently

2. Write CI marker to a temporary/untracked npmrc

➕ Keeps tracked .npmrc pristine without relying on git checkout
➕ Explicit scoping to a single command invocation
➖ Requires ensuring npm actually reads the intended file (e.g., --userconfig)
➖ More moving parts and potential divergence from local config behavior

3. Exclude .npmrc from persisted workspace

➕ Prevents downstream commit jobs from seeing the mutation
➕ Does not require install-step changes
➖ Risky: downstream jobs may depend on .npmrc presence/config
➖ Fixes the symptom (commit pollution) but not the local user-agent override if it gets committed again

Recommendation: The chosen EXIT-trap revert is a pragmatic, robust fix: it preserves the CI-only marker during install, guarantees cleanup on failure under bash -eo pipefail, and prevents workspace persistence from leaking tracked-file mutations into release commits. Environment-variable or temp-npmrc approaches could be cleaner long-term, but they depend on tool compatibility and propagation; this change is minimal and directly addresses the root cause.

Files changed (2) +12 / -13

Bug fix (1) +12 / -1

config.ymlRevert CI-only .npmrc mutation via EXIT trap during bbit install +12/-1

Revert CI-only .npmrc mutation via EXIT trap during bbit install

• Replaces the one-liner that appended to .npmrc with a multi-line command block. Adds an EXIT trap to git-checkout .npmrc after install so the tracked file is clean before persisting the workspace to downstream jobs.

.circleci/config.yml

Other (1) +0 / -12

.npmrcRemove accumulated duplicate user-agent entries +0/-12

Remove accumulated duplicate user-agent entries

• Collapses the file back to a single intended local user-agent entry. Eliminates duplicate-key last-wins behavior that previously forced local installs to present as CI.

.npmrc

qodo-free-for-open-source-projects · 2026-07-31T15:00:49Z

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Unprovisioned pnpm command 🐞 Bug ☼ Reliability

Description

setup_harmony now invokes pnpm config set without running the repository's setup_pnpm command,
so a missing pnpm terminates the && chain before bbit install, while an ambient older pnpm may
write the setting somewhere other than pnpm-workspace.yaml. The repository explicitly provisions
and pins pnpm 12 for every existing direct pnpm workflow, but this job omits that setup.

Code

.circleci/config.yml[696]

+            pnpm config set --location=project userAgent bit-repo-circleci &&

Evidence

setup_harmony reaches the added direct pnpm invocation after only Node/npm and BVM setup, and its
&& chain prevents bbit install when that invocation fails. The repository's sole explicit pnpm
provisioning is the separate setup_pnpm command, which installs version 12.0.0-rc.7 and configures
PATH; all existing bundle jobs that execute direct pnpm commands call it first.

.circleci/config.yml[264-279]
.circleci/config.yml[671-698]
.circleci/config.yml[1008-1021]
.circleci/config.yml[1114-1125]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`setup_harmony` directly invokes `pnpm config set`, but the job does not install or pin pnpm. This can either fail the job or use a pnpm version that does not implement the expected v12 project-config behavior.
## Issue Context
The repository already defines `setup_pnpm`, which installs pnpm 12.0.0-rc.7 and exports its binary directory through `$BASH_ENV`. Add that setup to `setup_harmony` before the direct pnpm invocation, or invoke the explicitly provisioned v12 binary by another reliable mechanism.
## Fix Focus Areas
- .circleci/config.yml[264-279]
- .circleci/config.yml[671-698]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Repo npmrc user-agent removed 🐞 Bug ◔ Observability

Description

The tracked .npmrc has been deleted and the setup_harmony job no longer sets
user-agent=bit-repo-circleci before running bbit install, removing the repo- and CI-level
explicit user-agent override. Since Bit’s pnpm integration reads the resolved npmrc/pnpm
config.userAgent to choose a network user-agent, installs may now run with a different
(fallback/default) user-agent than before.

Code

.npmrc[L1-13]

-user-agent=bit-repo-local
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci

Evidence

getNetworkConfig() consults pnpm’s resolved configuration and uses config.userAgent when it is
present, falling back when it is not, so removing a repository .npmrc entry directly affects what
value can be sourced from project config. Additionally, the setup_harmony job’s install step is
now only cd bit && bbit install and no longer includes the prior .npmrc append that set
user-agent=bit-repo-circleci, demonstrating that the CI-specific override has also been removed
for that job.

scopes/dependencies/pnpm/pnpm.package-manager.ts[312-320]
.circleci/config.yml[638-642]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR removes the explicit npm user-agent configuration by deleting the tracked `.npmrc` and by stopping `setup_harmony` from setting a CI-specific `user-agent=bit-repo-circleci` before `bbit install`. Because Bit’s pnpm integration derives the network user-agent from the resolved pnpm/npmrc config (`config.userAgent`) when available, this can change the user-agent used for network operations and remove the intended request-identification marker in CI.
## Issue Context
- Bit’s pnpm package manager uses the resolved pnpm config’s `userAgent` when present, and falls back when it is not.
- Previously, the repo had a `.npmrc`-level `user-agent` setting that influenced the resolved config.
- Previously, the `setup_harmony` job appended `user-agent=bit-repo-circleci` to `.npmrc` right before installing; now the job runs `cd bit && bbit install` without setting a user-agent.
- If a stable marker is still desired, CI-specific configuration should not be introduced via mutating tracked workspace state.
## Fix Focus Areas
- scopes/dependencies/pnpm/pnpm.package-manager.ts[312-320]
- .npmrc[1-13]
- .circleci/config.yml[638-642]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Tip of the day

💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit d06d5b6 ⚖️ Balanced

Results up to commit f80b0a2

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Unprovisioned pnpm command 🐞 Bug ☼ Reliability ⭐ New

Description

setup_harmony now invokes pnpm config set without running the repository's setup_pnpm command,
so a missing pnpm terminates the && chain before bbit install, while an ambient older pnpm may
write the setting somewhere other than pnpm-workspace.yaml. The repository explicitly provisions
and pins pnpm 12 for every existing direct pnpm workflow, but this job omits that setup.

Code

.circleci/config.yml[696]

+            pnpm config set --location=project userAgent bit-repo-circleci &&

Evidence

setup_harmony reaches the added direct pnpm invocation after only Node/npm and BVM setup, and its
&& chain prevents bbit install when that invocation fails. The repository's sole explicit pnpm
provisioning is the separate setup_pnpm command, which installs version 12.0.0-rc.7 and configures
PATH; all existing bundle jobs that execute direct pnpm commands call it first.

.circleci/config.yml[264-279]
.circleci/config.yml[671-698]
.circleci/config.yml[1008-1021]
.circleci/config.yml[1114-1125]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`setup_harmony` directly invokes `pnpm config set`, but the job does not install or pin pnpm. This can either fail the job or use a pnpm version that does not implement the expected v12 project-config behavior.

## Issue Context
The repository already defines `setup_pnpm`, which installs pnpm 12.0.0-rc.7 and exports its binary directory through `$BASH_ENV`. Add that setup to `setup_harmony` before the direct pnpm invocation, or invoke the explicitly provisioned v12 binary by another reliable mechanism.

## Fix Focus Areas
- .circleci/config.yml[264-279]
- .circleci/config.yml[671-698]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Repo npmrc user-agent removed 🐞 Bug ◔ Observability

Description

The tracked .npmrc has been deleted and the setup_harmony job no longer sets
user-agent=bit-repo-circleci before running bbit install, removing the repo- and CI-level
explicit user-agent override. Since Bit’s pnpm integration reads the resolved npmrc/pnpm
config.userAgent to choose a network user-agent, installs may now run with a different
(fallback/default) user-agent than before.

Code

.npmrc[L1-13]

-user-agent=bit-repo-local
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci

Evidence

getNetworkConfig() consults pnpm’s resolved configuration and uses config.userAgent when it is
present, falling back when it is not, so removing a repository .npmrc entry directly affects what
value can be sourced from project config. Additionally, the setup_harmony job’s install step is
now only cd bit && bbit install and no longer includes the prior .npmrc append that set
user-agent=bit-repo-circleci, demonstrating that the CI-specific override has also been removed
for that job.

scopes/dependencies/pnpm/pnpm.package-manager.ts[312-320]
.circleci/config.yml[638-642]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR removes the explicit npm user-agent configuration by deleting the tracked `.npmrc` and by stopping `setup_harmony` from setting a CI-specific `user-agent=bit-repo-circleci` before `bbit install`. Because Bit’s pnpm integration derives the network user-agent from the resolved pnpm/npmrc config (`config.userAgent`) when available, this can change the user-agent used for network operations and remove the intended request-identification marker in CI.
## Issue Context
- Bit’s pnpm package manager uses the resolved pnpm config’s `userAgent` when present, and falls back when it is not.
- Previously, the repo had a `.npmrc`-level `user-agent` setting that influenced the resolved config.
- Previously, the `setup_harmony` job appended `user-agent=bit-repo-circleci` to `.npmrc` right before installing; now the job runs `cd bit && bbit install` without setting a user-agent.
- If a stable marker is still desired, CI-specific configuration should not be introduced via mutating tracked workspace state.
## Fix Focus Areas
- scopes/dependencies/pnpm/pnpm.package-manager.ts[312-320]
- .npmrc[1-13]
- .circleci/config.yml[638-642]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit 1db165e

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Repo npmrc user-agent removed 🐞 Bug ◔ Observability

Description

The tracked .npmrc has been deleted and the setup_harmony job no longer sets
user-agent=bit-repo-circleci before running bbit install, removing the repo- and CI-level
explicit user-agent override. Since Bit’s pnpm integration reads the resolved npmrc/pnpm
config.userAgent to choose a network user-agent, installs may now run with a different
(fallback/default) user-agent than before.

Code

.npmrc[L1-13]

-user-agent=bit-repo-local
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci

Evidence

getNetworkConfig() consults pnpm’s resolved configuration and uses config.userAgent when it is
present, falling back when it is not, so removing a repository .npmrc entry directly affects what
value can be sourced from project config. Additionally, the setup_harmony job’s install step is
now only cd bit && bbit install and no longer includes the prior .npmrc append that set
user-agent=bit-repo-circleci, demonstrating that the CI-specific override has also been removed
for that job.

scopes/dependencies/pnpm/pnpm.package-manager.ts[312-320]
.circleci/config.yml[638-642]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR removes the explicit npm user-agent configuration by deleting the tracked `.npmrc` and by stopping `setup_harmony` from setting a CI-specific `user-agent=bit-repo-circleci` before `bbit install`. Because Bit’s pnpm integration derives the network user-agent from the resolved pnpm/npmrc config (`config.userAgent`) when available, this can change the user-agent used for network operations and remove the intended request-identification marker in CI.
## Issue Context
- Bit’s pnpm package manager uses the resolved pnpm config’s `userAgent` when present, and falls back when it is not.
- Previously, the repo had a `.npmrc`-level `user-agent` setting that influenced the resolved config.
- Previously, the `setup_harmony` job appended `user-agent=bit-repo-circleci` to `.npmrc` right before installing; now the job runs `cd bit && bbit install` without setting a user-agent.
- If a stable marker is still desired, CI-specific configuration should not be introduced via mutating tracked workspace state.
## Fix Focus Areas
- scopes/dependencies/pnpm/pnpm.package-manager.ts[312-320]
- .npmrc[1-13]
- .circleci/config.yml[638-642]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit 4de67bf

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Repo npmrc user-agent removed 🐞 Bug ◔ Observability

Description

The tracked .npmrc has been deleted and the setup_harmony job no longer sets
user-agent=bit-repo-circleci before running bbit install, removing the repo- and CI-level
explicit user-agent override. Since Bit’s pnpm integration reads the resolved npmrc/pnpm
config.userAgent to choose a network user-agent, installs may now run with a different
(fallback/default) user-agent than before.

Code

.npmrc[L1-13]

-user-agent=bit-repo-local
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci

Evidence

getNetworkConfig() consults pnpm’s resolved configuration and uses config.userAgent when it is
present, falling back when it is not, so removing a repository .npmrc entry directly affects what
value can be sourced from project config. Additionally, the setup_harmony job’s install step is
now only cd bit && bbit install and no longer includes the prior .npmrc append that set
user-agent=bit-repo-circleci, demonstrating that the CI-specific override has also been removed
for that job.

scopes/dependencies/pnpm/pnpm.package-manager.ts[312-320]
.circleci/config.yml[638-642]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR removes the explicit npm user-agent configuration by deleting the tracked `.npmrc` and by stopping `setup_harmony` from setting a CI-specific `user-agent=bit-repo-circleci` before `bbit install`. Because Bit’s pnpm integration derives the network user-agent from the resolved pnpm/npmrc config (`config.userAgent`) when available, this can change the user-agent used for network operations and remove the intended request-identification marker in CI.
## Issue Context
- Bit’s pnpm package manager uses the resolved pnpm config’s `userAgent` when present, and falls back when it is not.
- Previously, the repo had a `.npmrc`-level `user-agent` setting that influenced the resolved config.
- Previously, the `setup_harmony` job appended `user-agent=bit-repo-circleci` to `.npmrc` right before installing; now the job runs `cd bit && bbit install` without setting a user-agent.
- If a stable marker is still desired, CI-specific configuration should not be introduced via mutating tracked workspace state.
## Fix Focus Areas
- scopes/dependencies/pnpm/pnpm.package-manager.ts[312-320]
- .npmrc[1-13]
- .circleci/config.yml[638-642]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit 5cd15a5

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Repo npmrc user-agent removed 🐞 Bug ◔ Observability

Description

The tracked .npmrc has been deleted and the setup_harmony job no longer sets
user-agent=bit-repo-circleci before running bbit install, removing the repo- and CI-level
explicit user-agent override. Since Bit’s pnpm integration reads the resolved npmrc/pnpm
config.userAgent to choose a network user-agent, installs may now run with a different
(fallback/default) user-agent than before.

Code

.npmrc[L1-13]

-user-agent=bit-repo-local
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci
-user-agent=bit-repo-circleci

Evidence

getNetworkConfig() consults pnpm’s resolved configuration and uses config.userAgent when it is
present, falling back when it is not, so removing a repository .npmrc entry directly affects what
value can be sourced from project config. Additionally, the setup_harmony job’s install step is
now only cd bit && bbit install and no longer includes the prior .npmrc append that set
user-agent=bit-repo-circleci, demonstrating that the CI-specific override has also been removed
for that job.

scopes/dependencies/pnpm/pnpm.package-manager.ts[312-320]
.circleci/config.yml[638-642]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR removes the explicit npm user-agent configuration by deleting the tracked `.npmrc` and by stopping `setup_harmony` from setting a CI-specific `user-agent=bit-repo-circleci` before `bbit install`. Because Bit’s pnpm integration derives the network user-agent from the resolved pnpm/npmrc config (`config.userAgent`) when available, this can change the user-agent used for network operations and remove the intended request-identification marker in CI.

## Issue Context
- Bit’s pnpm package manager uses the resolved pnpm config’s `userAgent` when present, and falls back when it is not.
- Previously, the repo had a `.npmrc`-level `user-agent` setting that influenced the resolved config.
- Previously, the `setup_harmony` job appended `user-agent=bit-repo-circleci` to `.npmrc` right before installing; now the job runs `cd bit && bbit install` without setting a user-agent.
- If a stable marker is still desired, CI-specific configuration should not be introduced via mutating tracked workspace state.

## Fix Focus Areas
- scopes/dependencies/pnpm/pnpm.package-manager.ts[312-320]
- .npmrc[1-13]
- .circleci/config.yml[638-642]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit bdd8d67

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

qodo-free-for-open-source-projects · 2026-07-31T15:32:31Z

@@ -1,13 +0,0 @@
-user-agent=bit-repo-local


1. Repo npmrc user-agent removed 🐞 Bug ◔ Observability

The tracked .npmrc has been deleted and the setup_harmony job no longer sets user-agent=bit-repo-circleci before running bbit install, removing the repo- and CI-level explicit user-agent override. Since Bit’s pnpm integration reads the resolved npmrc/pnpm config.userAgent to choose a network user-agent, installs may now run with a different (fallback/default) user-agent than before.

Agent Prompt

## Issue description The PR removes the explicit npm user-agent configuration by deleting the tracked `.npmrc` and by stopping `setup_harmony` from setting a CI-specific `user-agent=bit-repo-circleci` before `bbit install`. Because Bit’s pnpm integration derives the network user-agent from the resolved pnpm/npmrc config (`config.userAgent`) when available, this can change the user-agent used for network operations and remove the intended request-identification marker in CI. ## Issue Context - Bit’s pnpm package manager uses the resolved pnpm config’s `userAgent` when present, and falls back when it is not. - Previously, the repo had a `.npmrc`-level `user-agent` setting that influenced the resolved config. - Previously, the `setup_harmony` job appended `user-agent=bit-repo-circleci` to `.npmrc` right before installing; now the job runs `cd bit && bbit install` without setting a user-agent. - If a stable marker is still desired, CI-specific configuration should not be introduced via mutating tracked workspace state. ## Fix Focus Areas - scopes/dependencies/pnpm/pnpm.package-manager.ts[312-320] - .npmrc[1-13] - .circleci/config.yml[638-642]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-free-for-open-source-projects · 2026-07-31T15:32:33Z

Code review by qodo was updated up to the latest commit 5cd15a5

qodo-free-for-open-source-projects · 2026-07-31T19:26:47Z

Code review by qodo was updated up to the latest commit 4de67bf

setup_harmony appended `user-agent=bit-repo-circleci` to the tracked .npmrc and then persisted the checkout, so the job that commits the version bump swept the mutated file into every release. The file had reached twelve copies of the line. The setting no longer does anything. pnpm v12 does not read `user-agent` from .npmrc: an install with `user-agent=bit-repo-local` in .npmrc sends the default `pnpm/<version> ...` header, and bit's own installs send `bit user/<username>` from getNetworkConfig, which reads bit config rather than .npmrc. Both names have been inert since the pnpm v12 migration, and before that the twelve committed CI lines overrode `bit-repo-local` for local work anyway, because the last duplicate key wins. Remove the append and the file instead of repairing a setting nothing reads. Local and CI installs now share one user agent, bit's own. The knobs that do work under v12, should this traffic ever need marking again, are `pnpm_config_user_agent` in the environment and `userAgent` in pnpm-workspace.yaml. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

qodo-free-for-open-source-projects · 2026-09-01T12:21:49Z

Code review by qodo was updated up to the latest commit 1db165e

The local and CI markers stopped working: pnpm v12 reads settings like `user-agent` from pnpm-workspace.yaml rather than .npmrc, and Bit resolves its network config through the package-manager config rather than the repository .npmrc. Set the tracked default to `userAgent: bit-repo` in pnpm-workspace.yaml. In setup_harmony, override it with `pnpm config set --location=project userAgent bit-repo-circleci` before installation so registry traffic from CI remains distinguishable. Mark the file skip-worktree so the persisted checkout does not sweep this temporary override into a later release commit. Verified the project config resolves each marker with pnpm v12. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

qodo-free-for-open-source-projects · 2026-09-01T12:25:46Z

            cd bit &&
-            echo "user-agent=bit-repo-circleci" >> .npmrc &&
-            git update-index --skip-worktree .npmrc &&
+            pnpm config set --location=project userAgent bit-repo-circleci &&


1. Unprovisioned pnpm command 🐞 Bug ☼ Reliability

setup_harmony now invokes pnpm config set without running the repository's setup_pnpm command, so a missing pnpm terminates the && chain before bbit install, while an ambient older pnpm may write the setting somewhere other than pnpm-workspace.yaml. The repository explicitly provisions and pins pnpm 12 for every existing direct pnpm workflow, but this job omits that setup.

Agent Prompt

## Issue description `setup_harmony` directly invokes `pnpm config set`, but the job does not install or pin pnpm. This can either fail the job or use a pnpm version that does not implement the expected v12 project-config behavior. ## Issue Context The repository already defines `setup_pnpm`, which installs pnpm 12.0.0-rc.7 and exports its binary directory through `$BASH_ENV`. Add that setup to `setup_harmony` before the direct pnpm invocation, or invoke the explicitly provisioned v12 binary by another reliable mechanism. ## Fix Focus Areas - .circleci/config.yml[264-279] - .circleci/config.yml[671-698]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-free-for-open-source-projects · 2026-09-01T12:25:48Z

Code review by qodo was updated up to the latest commit f80b0a2

qodo-free-for-open-source-projects · 2026-09-01T13:25:32Z

Code review by qodo was updated up to the latest commit d06d5b6

zkochan force-pushed the fix-npmrc-user-agent-append branch from bdd8d67 to 5cd15a5 Compare July 31, 2026 15:26

zkochan changed the title ~~fix(ci): stop the CI user-agent from accumulating in the tracked .npmrc~~ fix(ci): drop the dead .npmrc user-agent and its per-release append Jul 31, 2026

qodo-free-for-open-source-projects Bot reviewed Jul 31, 2026

View reviewed changes

zkochan changed the title ~~fix(ci): drop the dead .npmrc user-agent and its per-release append~~ fix(ci): move the repo user-agent to where pnpm v12 reads it Jul 31, 2026

GiladShoham approved these changes Sep 1, 2026

View reviewed changes

GiladShoham enabled auto-merge (squash) September 1, 2026 12:13

github-actions Bot mentioned this pull request Sep 1, 2026

Merge Queue Dashboard #10562

Open

zkochan force-pushed the fix-npmrc-user-agent-append branch from 4de67bf to 1db165e Compare September 1, 2026 12:20

zkochan force-pushed the fix-npmrc-user-agent-append branch from 1db165e to f80b0a2 Compare September 1, 2026 12:23

qodo-free-for-open-source-projects Bot reviewed Sep 1, 2026

View reviewed changes

Merge branch 'master' into fix-npmrc-user-agent-append

d06d5b6

Merge branch 'master' into fix-npmrc-user-agent-append

eef2eb1

github-actions Bot mentioned this pull request Sep 1, 2026

Merge Queue Dashboard #10681

Open

Navigation Menu

Uh oh!

fix(ci): move the repo user-agent to where pnpm v12 reads it - #10552

fix(ci): move the repo user-agent to where pnpm v12 reads it#10552
zkochan wants to merge 4 commits into
teambit:masterfrom
zkochan:fix-npmrc-user-agent-append

zkochan commented Jul 31, 2026 •

edited

Loading

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 31, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 31, 2026 •

edited

Loading

Great, no issues found!

Uh oh!

qodo-free-for-open-source-projects Bot Jul 31, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 31, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 31, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 1, 2026

Uh oh!

qodo-free-for-open-source-projects Bot Sep 1, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 1, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

zkochan commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What this PR does

Squash Commit Body

Checklist

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 31, 2026

PR Summary by Qodo

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Great, no issues found!

Uh oh!

qodo-free-for-open-source-projects Bot Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 31, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Jul 31, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 1, 2026

Uh oh!

qodo-free-for-open-source-projects Bot Sep 1, 2026

Choose a reason for hiding this comment

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 1, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

zkochan commented Jul 31, 2026 •

edited

Loading

qodo-free-for-open-source-projects Bot commented Jul 31, 2026 •

edited

Loading